Object-oriented programming paradigms have become an increasingly common tool in computer programming. Such paradigms are often employed by graphical user interfaces, where computer system elements are visually represented and manipulated by visible screen entities such as icons on a computer screen or other display device. For programming purposes, "objects" are used to represent the manipulatable computer system elements by containing methods and data that define those elements. By representing such computer system elements as objects, it is unnecessary for the programmer to generate a specific set of code for each computer system element. Rather, the programmer can define classes of objects and assign certain universal behaviors to each class. Computer system elements that can be represented by objects include computer peripherals and computer application programs. Examples of application programs are spreadsheets, word processing programs, database programs, etc.
In graphical user interfaces employing an object-oriented programming paradigm, application programs are typically represented to a user by an icon displayed within a window on a computer screen, one icon for each application program that can be run. Execution of an application program is initiated by selecting its corresponding icon, most often using a pointing device such as a mouse. When an application program is selected, a message is sent to the corresponding application program object, indicating that the application program object is to invoke certain of its methods. For example, if a word processing program is selected, the methods contained within the application program object may include starting the word processing program. The user may also "drag" icons from one area of the screen to another, or from one window to another using the mouse. The user may even "drag" one icon representative of an application object and "drop" that icon on top of another. This "object-object" interaction will result in a combination of application objects. For example, if a word processing document icon is dropped upon a word processing program icon, the object-object interaction results in starting the word processing program and causing that program to open the word processing document. This is possible because both the word processing program and the word processing document have been represented as compatible application program objects. Hence, the icons in the object-oriented programming paradigm allow the user to graphically control various computer system elements and the interrelationships between computer system elements.
While the conventional object-oriented, graphical user interface described above has been used to allow a user to initiate execution of such computer system elements as applications programs, use of object-oriented programming paradigms to graphically control and monitor non-computer system devices has been severely limited. Non-computer system devices include virtually any electronic device equipped with the necessary hardware to be connected to a personal computer either directly or via a network. For example, non-computer system devices may include lamps, television sets, VCRs, video cameras, telephones, amplifiers, CD players, equalizers, etc. Such devices typically come equipped with a variety of feature controls and displays for operation including volume controls, power switches, input and output meters, channel selectors, etc. In order to control a non-computer system device using a graphical user interface, in the past, each feature control (e.g., a volume control) or feature display (e.g., an output meter) that is to be manipulated by the user has been coupled to the graphical user interface computer by specially designed software, resulting in a visible screen entity for each feature control of the device being displayed on the computer screen.
Conventionally, non-computer system devices have been graphically represented and controlled via a special program designed specifically for each device, where the specially designed program is either built into the computer operating system or loaded into the computer operating system as an add-on software product. For example, the CD Remote program, Version 1.3 for the Macintosh computer provides the computer user with a graphic interface for controlling a Macintosh CD player hardwired to the computer. The user is provided with a graphical display of the CD player's control panel, complete with graphical stop, play, pause, skip, etc. controls. To initiate execution of any one of these commands upon the CD player, the user merely selects the corresponding graphical control using the mouse. Unlike graphical user interface programs for controlling applications programs, the graphical controls are not visible screen entities that the user can "drag and drop" or "cut and paste" into other areas of the screen, into other windows, or on top of one another. Instead, the placement, position and execution of each of the graphical controls is predefined by the specially designed CD Remote program for the CD player.
In contrast to the Macintosh CD player, non-computer system devices are normally not used alone. Instead, non-computer system devices are used in combination with other non-computer system devices. For example, a stereo system often comprises at least a CD player, an equalizer and an amplifier, each of which may be made by the same or a different manufacturer. In order to use a personal computer to operate an entire stereo system using the approach employed by the CD Remote program referred to above, each stereo system device would be necessarily be hardwired to the personal computer and a specially designed program comprising specific sets of code would be necessary for controlling each device, each feature control, and each feature display on each device, and for controlling the relationships between the devices and the feature controls and displays. In addition, the code would have to be specially designed for each manufacturer's device. Even if the devices were connected to the personal computer via a network as opposed to directly hardwired, specialized code would still be required to control each device because, prior to the present invention, a graphic user interface employing an object-oriented programming paradigm for controlling stereo devices produced by varying manufacturers did not exist.
Accordingly, there is a need for a graphical control system for controlling non-computer system devices and the relationships between those devices. In order to eliminate the need for specially designed code for each device, such a graphical control system should employ a common paradigm for representing the non-computer system devices to be controlled. In addition, the graphical control system should provide for dynamic visual device controls that represent each feature control of a device and allow a user to graphically control and monitor each device without having any specific knowledge about the device and without making any physical contact with the device. The present invention is directed to providing such a graphical control system.